home *** CD-ROM | disk | FTP | other *** search
- Path: hilbert.dnai.com!usenet
- From: Victor Bazarov <vbazarov@imsisoft.com>
- Newsgroups: comp.lang.c
- Subject: Re: Floating point calculation order
- Date: Thu, 25 Jan 1996 17:53:42 -0800
- Organization: IMSI
- Message-ID: <31083426.197A@imsisoft.com>
- References: <m0tedv8-0002eqC@sice.nsk.su>
- NNTP-Posting-Host: 204.182.61.84
- Mime-Version: 1.0
- Content-Type: text/plain; charset=us-ascii
- Content-Transfer-Encoding: 7bit
- X-Mailer: Mozilla 2.0b4a (Win16; I)
-
- Pavel A. Zemtsov wrote:
- >
- > Having declaration
- >
- > double x, p, q, r;
- >
- > my compiler (cc on SCO 3.2) calculated following expression:
- >
- > x = p * q / r;
- >
- > as p * (q/r); (I mean, it divided first, than multiplied). That
- > resulted in precision loss.
- >
- > Is this legal behavior?
-
- According to ISO/IEC 9899, it is implementation defined, I guess.
-
- On the page 7 the behaviour of the abstract machine is described:
-
- "In the abstract machine, all expressions are evaluated as specified
- by the semantics. An actual implementation need not evaluate part
- of an expression if it can deduce that its value is not used and
- that no needed side effects are produced (including any caused by
- calling a function or accessing a volatile object)."
-
- From the wording it is not immediately clear if compiler is allowed
- to rewrite the expression. But in the example on the page 9 one can
- conclude that the expression a + 32760 + b + 5 can be rewritten as
- ((a + 32765) + b) on a machine without exceptions on integer overflow.
- So, in any case compiler vendor could say: 'Hey, I'm trying to help
- you here, avoiding overflow from multiplication.', although at the
- closer look, division can produce similar overflow...
-
- I few words, put the braces the way you want the expression to be
- evaluated, and complain if compiler does not obey them.
-
- >
- > Thank you.
- >
- > Pavel A.Zemtsov pasha@sice.nsk.su
-
- Victor.
-
- --
- Signature.
-